AWS Step Functions

https://gyazo.com/baa25574fcf0ed62eeb78d408a2c997d

hiroki.icon

実行状態のマネージとサービスと言える

グローバルに実行状態のjsonを持ってくれて、その状態に対して更新したり持ち回ったり状態を参照出来る。これによってプロセスをオーケストレイトするのに加えて処理の引数をマネージドできる

プロセス（呼び出す個々の処理lambda,batch...）、フロー（全体の処理の流れ）、ステート（状態）というアルゴリズム構築のエッセンスがくっきりと浮かび上がってる筋の良いサービスかも

→ワークフローにした時の情報の整理された感じが美しい

概要

AWS SWF

ステートマシーン

プロセスオーケストレータ/サーバーレス関数オーケストレーター

StepFunctions自体は処理(計算)をしない

処理(lambda、batch...)をオーケストレイトするのみ

計算が必要になるような条件分岐判断はlambdaなどのコンピューティングを使う必要がある

状態遷移1000回ごとの課金なので処理待ち時間などが長くてもその分の料金はかからない

処理先でのコンピューティング料金はもちろんかかるよ

digdagとか準備するよりも、サーバレスだしStepFunctionsで済ませた方が運用とかなくて楽になりそうだな

ローカルでの実行とかできないからデバッグとかはやりにくい

Step Functions Local(dockerイメージ)でローカル実行デバッグは可能

処理自体（プロセス）と制御を明確に分離することで処理と制御が疎結合になり全体のワークフローの見通しがよくなる

メリットとしては実行時にリトライやタイムアウトといったアプリケーション本体とは異なる要件をJSON記法で指定できること。これにより、ECSタスクの実行にタイムアウトを設定できたりする

「バッチの依存関係をスケジュール実行の時間で管理している」みたいな場合はstepfunctionsで一気に改善できるだろうね

失敗したステートから再実行できないのがwfシステムとしてはツラい

お気持ち

一つのプログラミング言語でホストして記述すれば簡単にできたテストとか実行とかがやりにくくなるよなぁ。DX体験が損なわれる。

クラウドネイティブになったことでプログラミング言語以上に抽象度の高い専門性のあるコンポーネントが当然のようにワークロードに組み込まれるようになった。これによってプログラミング言語に閉じた制御という枠組みから出るというこのサービスとかが生まれたのかも。

逆にクラウドネイティブなコンポーネントが出てこないようなレガシーなシステムだと不必要だ

下手に利用するとロジックがサイロ化しそう

サービスとの連携

現在はほぼ全てのサービスをトリガーできる

ユースケース

API Gatewayとstep functionsでサーバレスでかつ複数のawsサービスをオーケストレーションする必要のあるバックエンドを実現できる

API gatewayからstepfunctionsをトリガーできる

人間の入力、承認待ちといったフローがある処理

一年までwaitできる

参照

https://youtu.be/PGyasNJ1QTQ

https://gyazo.com/6f2c81177fe50f672c0fa6ceb2053825

https://gyazo.com/e9d9b29b6926869c032033551a823f64

https://gyazo.com/e09fdc3da82bb8eccc5c77b765f8d0de